From time to time I've to use chromium for creepy stuff like lifesize video conferencing with document sharing. The document sharing requires a chromium extension. Suddenly that stopped working today and I could not reinstall the extension. After trying a lot of stuff I had a look at the debian changelog and found out about:

chromium --enable-remote-extensions

See also #851927.

While reading the Tails 2.10 changelog I stumbled upon the fact that Tails now supports exFAT. Since Tails is Debian based I just checked the image and indeed it contains the fuse-exfat package. Do I've to assume that I've now another set of crosshairs on my back just because it's one possible maintainer you could attack to place malicious code into Tails? I'm not sure, and I'm also not sure if it would change much. I've always assumed to be a target just because I'm contributing to Debian, and because I'm working in IT operations. But to be honest so far my contributions to Debian are not on crucial packages and unexpected strange looking NMUs would always raise alarm bells for everyone. BTW the exfat fuse driver package builds reproducible. Maybe a good opportunity to thank the reproducible build team for this effort!

I started to reactivate my old moto g falcon during the last days of CyanogenMod in December of 2016. First step was a recovery update to TWRP 3.0.2-2 so I was able to flash CM13/14 builds. While CM14 nightly builds did not boot at all the CM13 builds did, but up to the last build wifi connections to the internet did not work. I could actually register with my wifi (Archer C7 running OpenWRT) but all apps claim the internet connection check failed and I'm offline. So bummer, without wifi a smartphone is not much fun. I was pretty sure that wifi worked when I last used that phone about 1.5 years ago with CM11/12, so I started to dive into the forums of xda-developers to look for alternatives. Here I found out about Exodus. I've a bit of trouble trusting stuff from xda-developer forums but what the hell, the phone is empty anyway so nothing to loose and I flashed the latest falcon build. To flash it I had to clean the whole phone, format all partitions via TWRP and then sideloaded the zip image file via adb (adb from the Debian/stretch adb package works like a charm, thank you guys!). Booted and b m wifi works again! Now Exodus is a really striped down mod, to do anything useful with it I had to activate the developer options and allow USB debugging. Afterwards I could install the f-droid and Opera apk via "adb install foo.apk". Lineage OS As I could derive from another thread on xda-developers Lineage OS has the falcon still on the shortlist for 14.x nightly builds. Maybe that will be an alternative again in the future. For now Exodus is a bit behind the curve (based on Android 6.0.1 from September 2016) but at least it's functional.

Just a short PSA for those around working with F5 devices: TMOS 11.6 introduced an experimental "mv" command in tmsh. In the last days we tried it for the first time on TMOS 12.1.1. It worked fine for a VirtualServer but a mv for a pool caused a sefault in tmm. We're currently working with the F5 support to sort it out, they think it's a known issue. Recommendation for now is to not use mv on pools. Just do it the old way, create a new pool, assign the new pool to the relevant VS and delete the old pool. Possible bug ID at F5 is ID562808. Since I can not find it in the TMOS 12.2 release notes I expect that this issue also applies to TMOS 12.2, but I did not verify that.

A friend of mine choose for $reasons to install the latest OpenSuSE 42.2 release as his new laptop operating system. It's been a while that I had contact with the SuSE Linux distribution. Must be around 12 years or so. The unsual part here is that I've to support a somewhat eccentric, but mostly ordinary user of computers. And to my surprise it's still hard to just plug in your existing stuff and expect it work. I've done so many dirty things to this installation in the last three days, my system egineering heart is bleeding. printing with a Canon Pixma iP100 printer This is a small portable Canon printer, about four years old. It provides a decent quality and its main strength is that it's small and really portable. Sadly the gutenprint driver just pushes through a blank page. No ink wasted on it at all. So the only reasonable other choice was a four year old binary rpm package provided by Canon. It has a file dependency on "libtiff.so.3" which is no longer available in recent GNU/Linux distributions. So I cheated and

- unpacked the tarball
- installed the rpm from the "packages" folder
zypper install cnijfilter-common-3.70-1.x86_64.rpm cnijfilter-ip100series-3.70-1.x86_64.rpm
... and choose to ignore the missing file dependency on libtiff.so.5.
ln -s /usr/lib64/libtiff.so /usr/lib64/libtiff.so.5
- re-ran the ./install.sh which registered the printer with cups and does whatever else
  magic is included in 1906 lines of shell.

To my surprise this driver still works and provides the expected quality. Though it's just a question of time until this setup will break. Be it an incompatible ABI change in libtiff or another lib in use by those Canon provided tools. QGIS and gdal with ECW support While the printer stuff is a rather common use case, having a map viewer for map files in the ECW format is the eccentric part. I found some hints on stackoverflow and subsequently https://trac.osgeo.org/gdal/wiki/ECW that a non-free library is required and a specific build of gdal. Then QGIS should be able to work with ECW files. Lucky us there is at least a OpenSuSE repository for gdal and QGIS. So I did the following:

zypper addrepo http://download.opensuse.org/repositories/Application:/Geo/openSUSE_Leap_42.2/Application:Geo.repo
zypper install qgis

Then I had to download the non-free ECW SDK from http://download.hexagongeospatial.com/downloads/erdas-ecw-jp2-sdk-v5.3-%28linux%29 - you'll and up with a '.bin' installer file. The installation process left me with "ERDAS-ECW_JPEG_2000_SDK-5.3.0" folder in my $HOME. I moved that one to /opt. Next step is adding the library to the ldconfig search path.

echo "/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only/lib/x64/release/" > /etc/ld.so.conf.d/ecw.conf; ldconfig

Now it was "just" about rebuild gdal with ECW support. So I downloaded the required source packages with "zypper source-install gdal", edited the spec somewhere in "/usr/src/" to make the following modifications

--with-ecw=/opt/ERDAS-ECW_JPEG_2000_SDK-5.3.0/Desktop_Read-Only

added to the "./configure" invocation. And somewhere at the top we had to relax the requirement that all installed files have to be referenced inside the package.

%define _unpackaged_files_terminate_build 0

As a last step I had to "rpmbuild -ba" the package and force the installation via zypper once more, because this time we have a file depedency on the libecw stuff and it's obviously not listed in the rpm database. Last but not least I tried to put the gdal build on hold with

zypper addlock gdal libgdal20

to ensure it's not removed on the next update. Other non-free tools Beside of those two issues I had to install a range of other non-free tools, but currently they work without further issues or modifications. One is Teamviewer (i686 multiarch rpm) and the other one is XnViewMP. XnView is also able to show ECW files, but only the smaller ones. It crashes on bigger ones but that's also the case on Windows. Then there is also (required by some Italian map related websites) the ugly Adobe Flash Plugin for Firefox, but that one is sadly still a widespread issue. We also tried to try out the nvidia graphic drivers but at the moment we could only get the build in Intel card to work. Usually the preferred solution from my point of view but sometimes we see rendering glitches and I'm not sure if it's the driver or something else. my personal take away I hate to admit it but it's nothing extraordinary that was requested here. But still it took me the better part of two evenings to figure everything out. And even now it's not properly integrated and doomed to fail any day due to various updates and changes in the surounding ecosystem. I've full sympathy for every average user that would give up after two hours of research and try&error on this journey. For the printer drivers I'm happy to blame Canon. The printer situation as a whole improved from my point of view during the last decade, but it's still a pain in the ass with the very short shelf life you usually see with consumer models. For the ECW case one could discuss if it would be legally possible and helpful to do ugly dlopen() stuff to dynamcially load the shared libs. But then again someone has to make his hands dirty during the build and discussions about the legal use of header files will be the next chapter (hello Oracle). It's just ugly. Actually I know too little about the world of image formats to judge if someone has a good reason to keep this format commercial or not. From my personal point of view it's not useful and maybe even morally wrong. Technically one could argue if it would make sense to keep a local copy of the gdal build in "/opt" and start QGIS with a modified library path to prefer the private gdal build. Not sure if that is any better. On the other hand there are evolving mechanism like flatpack that would ease the handling of such situations. Buth then again we would be catering non-free software. It feels a lot like giving up. While my private working environment is except for firmware blobs free, I now created for someone a real "FrankenSuSE" to satisfy his everyday needs. On the one hand we now have another mostly satisfied user of a mostly free operating system. On the other hand that was only possible by adding a vast amount of non-free software. For sure we did not win the war, I'm not even sure if we've won a single battle here. It's just frustrating to see what is required to get someone up and running. With my personal attitude towards open source software it even feels wrong to invest so much time into fiddling with non-free components. What is still missing We currently lack an image viewer that allows us to print only a selection of an image, which is useful to print parts of a map. That usually works with XnView on Windows but does not work with the Linux version at the moment. I also tried gwenview and geeqie and had the same issue. Not sure if it's maybe a bug in XnView or one of the Qt parts (gwenview is also Qt based). I did not research that yet. Update: I spent quite some time looking into open bug reports for geeqie and gwenview. Seems the feature to print only a section of an image is something new. I've created #374299 (gwenview) and #457 (geeqie). For XnView I expect it's a difference between XnViewMP (the portable version) and the Windows only XnView Classic. Needs to be clarified and it might be worth to try XnView Classic with wine. Maybe printing with wine via cups works, I found at least some results for it on the internet.

No, not about the latest NOFX record, though it's a great one. Buy it. Took me a hell of a long time to get my head out of my arse and dive again into some Debian related work. Thanks to Nik for pushing me from time to time. So I've taken the time to upload LyX 2.2.2 to unstable and it's now build with Qt5. Afterall the package is still missing a lot of love, but I hope we've once again something for the upcoming stable release, that is close to the latest upstream stable release. If you use LyX please give it a try. For myself it's now the 6th year that I stopped using LyX after maintaining it for five years. And still I'm sponsoring the uploads and try to keep it at least functional. Strange how we sometimes take care of stuff even if we no longer have an active use for them.

Since I kind of recommended the free WoSign CA in the past, I would like to point out the issues that have piled up. Mozilla has a writeup due to a removal discussion for NSS: https://wiki.mozilla.org/CA:WoSign_Issues (Yes I'm late with this post, about a month or two by now ...) Since WoSign, or the person behind it, silently also bought StartCom we've now with StartSSL and WoSign two of the three free CAs in one hand with a questionable track record. That leaves everyone looking for a low budget option with Let's Encrypt.

... or the day I fixed my mail clients running on Debian/stretch. First of all mutt failed to open html mails or the html multipart stuff in Firefox. I found some interesting hints in a recent thread on debian-user. So now my "~/.mailcap" looks like this:

text/html; /usr/bin/firefox --new-tab %s;
text/html; /usr/bin/elinks -force-html -dump %s; copiousoutput

and I added the proposed "~/.muttrc" addition verbatim:

bind  attach  <return>  view-mailcap
alternative_order text/plain text/html
unauto_view *
auto_view text/html

For work related mails, where the use of html crap mails is a sad reality I can not avoid, I stick to Icedove. But beside of the many crashes everyone encountered recently it also crashes when I try to reach "Preferences -> Advanced -> Config Editor". So no chance to adjust the handling of http/https links in the UI. Luckily that configuration is still text, well XML, in a file called mimeTypes.rdf in in the profile directory. So I manually replaced "/usr/bin/iceweasel" with "/usr/bin/firefox" and a restart later clicking on http and https links works again. Yay.

Finally I got around taking a look at man libinput. And now with

Option "NaturalScrolling" "1"

in my xorg configuration multitouch scrolling works again in a natural way. What a relief, should've taken the 5 minutes to find that out a week ago.

I think my demands for a terminal emulator are pretty basic but none the less I run into trouble every now and then. This time it was a new laptop and starting from scratch with an empty $HOME and the current Debian/testing instead of good old Jessie. For the last four or five years I've been a happy user of gnome-terminal, configured a mono space font, a light grey background with black text color, create new tabs with Ctrl-n, navigate the tabs with Ctrl-Left and Ctrl-Right, show no menubar, select URLs with double click. Suited me well with my similarly configured awesome window manager, where I navigate with Mod4-Left and Mod4-Right between the desktops on the local screen and only activate a handful of the many default tiling modes. While I could get back most of my settings, somehow all cited gconf kung-foo to reconfigure the URL selection pattern in gnome-terminal failed, and copy&pasting URLs from the terminal was a pain in the ass. Long story short I now followed the advice of a coworker to just use the xfce4-terminal. That still required a few tweaks to get back to do what I want it to do. To edit the keybindings you've to know that you've to use the GTK way and edit them within in the menu while selecting the menu entry. But you've to allow that first (why oh why?):

echo "gtk-can-change-accels=1" >> ~/.gtkrc-2.0

Fair enough that is documented. Changing the keybinding generates fancy things in ~/.config/xfce4/terminal/accels.scm in case you plan to hand edit a few more of them. I also edited a few things in ~/.config/xfce4/terminal/terminalrc:

MiscAlwaysShowTabs=TRUE
MiscMenubarDefault=FALSE

So I guess I can remove gnome-terminal for now and stay with another GTK2 application. Doesn't feel that good but well at least it works.

Not sure what to say on days when the default ruleset of a "web application firewall" denies access for curl, and the circumvention is as complicated as:

alias curl-vs-asm="curl -A 'Mozilla'"

It starts to feel like wasting my lifetime when I see something like that. Otherwise I like my job (that's without irony!). Update: Turns out it's even worse. They specifically block curl. Even

curl -A 'A' https://wherever-asm-is-used.example

works.

To state the obvious: my personal preference is to run Debian GNU/Linux. My current workplace is a CentOS shop and usually I'm the first to claim that it doesn't matter at all, and distribution specific implementation details are irrelevant for what we do (running a JVM). Let's take a short detour to the RedHat network-scripts. Two weeks ago we found some systems we originally installed in a different network segment, with different DNS servers and different search domains, came back up after a reboot with a rewritten 'resolv.conf'. Later on cfengine replaced the generated 'resolv.conf' with the intended one, so it wasn't that obvious to spot in the first place. A colleague found the origin of the rewritten 'resolv.conf' in a device specific configuration file that defined the 'DNS 1,2 ' variables with the installation time DNS server IPs from the other segment. I expected to experience the same behaviour (resolv.conf rewritten during startup and replaced by cfengine later on) in other locations, but assumed we just didn't notice it because the main difference would be a slightly different list of search domains. And I was wrong. I checked the timestamps of several 'resolv.conf' files and their cfengine backup file. None were recently created or related somehow to a reboot. grep-ing through parts of the network-scripts I found the following conditional in '/etc/sysconfig/network-scripts/ifup'

if [ "$PEERDNS" != "no" ]  [ -n "$RESOLV_MODS" -a "$RESOLV_MODS" != "no" ]; then
   [ -n "$MS_DNS1" ] && DNS1=$MS_DNS1
   [ -n "$MS_DNS2" ] && DNS2=$MS_DNS2
      if [ -n "$DNS1" ] && ! grep -q "^nameserver $DNS1" /etc/resolv.conf &&
         tr=$(mktemp /tmp/XXXXXX) ; then
 ...

So if you adjust only the second nameserver IP you stored in "DNS2" in your configuration you end up without an update to your 'resolv.conf'. Now knowing that, I'd say this is relevant distribution specific knowledge, and I'm wondering how many of such subtle behaviours we've hidden in Debian specific solutions? Maybe knowledge about distribution specific implementation details even matters after all. Regardig the 'resolv.conf' issue itself the fault is on us. We as the responsible team did not read the documentation properly and thus deployed a configuration that later on let to some unexpected consequences. I try to remember those issues as an example for the next NetworkManager/systemd-networkd vs old-school-network-scripts argument.

Note to myself so I don't have to search for it the next time I've to answer security audit questions. If you're lucky and you're running Debian you can install pgpdump and use

gpg --export-options export-minimal --export $KEYID   pgpdump

to retrieve a human friendly output. If you're unlucky you have to use

gpg --export-options export-minimal --export $KEYID   gpg --list-packets

and match the CIPHER_ALGO_ and DIGEST_ALGO_ numbers with those in include/cipher.h. Found the information in this thread. Update: anarcat suggested to take a look at the tools contained in hopenpgp-tools.

Maybe my favourite song of Moby - "That's when I reach for my revolver" - is one of the more unsual ones, slightly more rooted in his Punk years and a cover version. Great artist anyway.

In case someone is in need of a free DynDNS service which allows you to configure AAAA recods and the TTL, you might want to look at BLABLADNS. It's rather HTTP API centric so you can configure everything with curl if you like.

Well we want to freeze later this year so I started with the axing now. Maybe a bit premature like Mattia pointed out correctly in #debian-qa, because we've some maintained plugins for xchat around. cwirc a morse code via IRC plugin xchat-xsys system statistics output to a channel Update: There is a xsys plugin included with hexchat. xchat-guile GNU Scheme scripting plugin Update: Lionel agreed and created a RM bug. Thanks! I can survive without them, so I'd be fine with another three RM bugs. Now feel free to flame me, I promise to wear my finest asbestos underwear.

I did some musings on my way home about a line of shell scripting similar to

if [  grep foobar somefile    wc -l  -gt 0 ]; then ...

Yes it's obvious that silencing grep and working with the return code is way more elegant and the backticks are also deprecated, or at least discouraged, nowadays. For this special case "grep -c" is not the right replacement. Just in case. So I wanted to know how widespread the "grep wc -l" chaining actually is. codesearch.d.n to the rescue! At least in some codebases it seems to be rather widespread, so maybe "grep -c" is not POSIX compliant? Nope. Traveling back a few years and looking at a somewhat older manpage also lists a "-c" option. At least for now I doubt that this is some kind of backwards compatiblity thing. Even busybox supports it. As you can obviously deduce from the matching lines, and my rather fuzzy search pattern, there are valid cases among the result set where "grep" is just the first command and some "awk/sed/tr" (you name it) is in between the final "wc -l". But quite some " wc -l" could be replaced by a "-c" added to the "grep" invocation.

[root@adc:Standby:In Sync] config # tmsh save /sys ucs /var/tmp/foo.ucs
Saving active configuration...
/var/tmp/foo.ucs is saved.
[root@adc:Standby:In Sync] config # tmsh save /sys ucs /var/tmp/foo.ucs > /dev/null
Saving active configuration...
[root@adc:Standby:In Sync] config # tmsh save /sys ucs /var/tmp/foo.ucs 2> /dev/null
/var/tmp/foo.ucs is saved.
[root@adc:Standby:In Sync] config #

Seems F5 is not alone with such glorious ideas. A coworker pointed out that the "ipspace list" command on our old NetApps outputs a space and a backspace in some places.

Today I learned from my coworkers about a few helpful sub commands of yum and some other things from the rpm world. Just jotting them down here so I don't forget about them. Oh and why did we've to do it? Well CentOS 6 got a grep update from 2.6 to 2.20. That upgrade lost the --mmap option and some very old stuff started to fall apart because of the now unknown option. Update: There are some interesting issues related to this update in the RedHat Bugzilla. #1287074 #1256756 I added #1291714 just for the sake of completeness.

# yum history
ID       Login user                 Date and time      Action(s)        Altered
-------------------------------------------------------------------------------
124   xxx                        2015-12-15 11:51   Downgrade           1
123   yyy                        2015-12-15 11:02   E, O, U           244 EE
122   zzz                        2015-12-15 10:57   I, O, U           255 **

Provides an overview of the last actions done with yum. On CentOS 7 (this one is from CentOS 6) the output seems to have changed slighty and it provides the commandline instead of the username.

# yum list installed   grep epel
bash-completion.noarch             1:1.3-7.el6                      @epel-Mirror
eventlog.x86_64                    0.2.13-1.el6                     @epel-Mirror
libnet.x86_64                      1.1.6-7.el6                      @epel-Mirror
pylint.noarch                      1.3.1-1.el6                      @epel-Mirror
python-astroid.noarch              1.2.1-2.el6                      @epel-Mirror
python-logilab-common.noarch       0.62.1-2.el6                     @epel-Mirror
python-unittest2.noarch            0.5.1-3.el6                      @epel-Mirror

Helps you to find out from which repository you installed which package.

# repoquery -i grep
Name        : grep
Version     : 2.20
Release     : 3.el6_7.1
Architecture: x86_64
Size        : 1197808
Packager    : CentOS BuildSystem <http://bugs.centos.org>
Group       : Applications/Text
URL         : http://www.gnu.org/software/grep/
Repository  : update
Summary     : Pattern matching utilities
Source      : grep-2.20-3.el6_7.1.src.rpm
Description : [ ... ]

Kind of the rpm -q ... stuff on a repository level instead of the local rpm database. Update: T.P. provided a small shell snippet to show updates. Thanks.

Something that made my day this week was a 2015 version of Alanis Morissette Ironic. It's even a bit more ironic when you're partially cought in a hands clean situation.